Also note MPTCP can be configured to perform both handshakes
simultaneously. This can improve the overall throughput due to
shorter handshake time, but it incurs energy overhead, and may
bring limited improvement when one path has long latency. We
propose a scheme in §4 that boosts the multipath performance by
reducing the number of handshakes from many to zero.
MPTCP Performance. How much performance benefits does
MPTCP provide? Here we focus on a simple metric – the transport-
layer throughput, and study application QoE later in §3.2 and §3.3.
Figure 4 studies five flow size groups within each four schemes
are compared: SPTCP over cellular, SPTCP over WiFi, cellular-
primary MPTCP, and WiFi-primary MPTCP. We normalize the
measured throughput at a per-group basis with the maximum
throughput in each group (normalized to 1) annotated. Also note
for Figure 4, we ignore all flows with inter-packet-arrival time
greater than 1s to ensure the flow is not likely to be throttled by
application.
We make two observations from Figure 4. First, for small flows
(less than 100KB), SPTCP over WiFi provides good throughput
that usually outperforms MPTCP. This is because latency plays a
more important role in determining small flows’ performance than
bandwidth does, and in our dataset WiFi usually has a smaller
RTT than cellular so transferring the entire flow over WiFi may
provide better performance. A question one may ask is, given
MPTCP’s scheduler selection the path with the smallest RTT, why
does MPTCP not perform at least as well as SPTCP? The reason is,
the above path selection only happens when both paths have spaces
in congestion window (cwnd). If, for example, WiFi’s cwnd is full
but LTE has empty cwnd space, the data will still be transferred
over LTE even if its latency is higher. This explains why MPTCP
may incur worse performance than SPTCP does. We will improve
this in §4.
The second observation from Figure 4 relates to large file
download where throughput is more important than latency. In this
case MPTCP always achieves higher throughput than SPTCP does.
Here we see the selection of the primary path still matters even
for large files. WiFi-primary MPTCP outperforms cellular-primary
because, as mentioned before, the long subflow handshake time of
LTE prolongs the overall download time. Also note that for both
MPTCP and SPTCP, flows with larger sizes achieve statistically
higher throughput, as the links are more likely to be saturated for
larger flows.
The performance of both SPTCP and MPTCP is also affected
by the latency of the corresponding path(s). In our dataset, WiFi
usually has a smaller RTT than cellular (even when we exclude the
university WiFi traffic that naturally has low WiFi RTT between the
client and the proxy). This aligns with recent measurement studies
of WiFi and cellular performance [17, 36]. We will systematically
study the performance impact of proxy location (and thus the
latecny) in §5.5.
Radio Energy is the energy consumed by the radio interface.
It accounts for a significant fraction of the overall mobile device
energy consumption in particular for cellular (1/3 to 1/2 for 3G [32]
and at least 50% for LTE [26]). Multipath impacts the radio energy
consumption in two ways. First, in many cases, it obviously incurs
additional energy footprint by using multiple interfaces. Second,
if properly leveraged, it may reduce the energy consumption by
shortening the file transfer time. In reality, how energy (in)efficient
is MPTCP compared to SPTCP? To answer this, we feed the
collected trace using the LTE/WiFi radio energy models developed
by Nika et al. [26] for SGS3, and compute the radio energy
consumption. Recall that in the user study, for each user, the data
collector re-configures its multipath setting every 24 hours. We
found that for MPTCP configurations, their average radio power
is 2.08 times of that for the SPTCP configuration. Based on this,
we can roughly estimate the impact of multipath on the overall
device battery drain. Assuming for single-path, the radio power
(either WiFi or cellular) accounts for 25% of the overall device
energy consumption [12], enabling system-wide MPTCP shortens
the battery life by 21%. We admit though this is a coarse-grained
estimation, and it is an upper bound that does not consider the
reduced radio energy due to MPTCP’s shorter transfer time. We
believe this overhead is not unreasonably high, and expect it to be
further reduced by using energy-aware policies described later.
Mobile Apps over MPTCP. We pick the five most-heavily used
apps by the 15 users over MPTCP to study the resource impact of
the cellular subflow. For each app, we plot the fraction of cellular
bytes and cellular radio energy as shown in Figure 5. For four
out of the five apps, less than 10% of the bytes are delivered over
cellular (due to the small flow sizes as explained earlier), while
the cellular energy accounts for more than 50% of the total radio
energy consumption. For most small flows using WiFi-primary
MPTCP, additional energy penalty comes from the fact that even
if LTE carries no user payload, the LTE interface still needs to
be activated for handshake. This occurs in 91% of the flows with
sizes less than 100KB. For these flows, 63% of the radio energy is
consumed by cellular that does not deliver any user payload. The
energy efficiency increases with larger flows, e.g., for YouTube.
Overall, our findings suggest that although multipath is energy-
wise expensive, by strategically leveraging it in an energy-aware
manner, the energy overhead can be reasonable and manageable.
Some recent work such as eMPTCP [39] has made a first
step toward this goal. We believe that besides improving
the scheduler [39], another important premise for energy-aware
multipath is to have per-application policy, as different apps incur
different cost-benefit tradeoffs when using multipath. We study this
in more depth in §3.2 and §3.3, and propose a system to allow easy
deployment of user policies (§4).
3.2 Active Measurements of User Study
We now shift our focus to the crowd-sourced active measurement
results. Complementing the passive measurement, active
measurements provide insights of how multipath impacts the
application performance.
File download. We collected 4,371 measurements of
downloading a 10MB file using single- and multipath. MPTCP
improves the file download performance by 34% in average. Note
that the MPTCP throughput is smaller than the sum of both paths’
throughput. We found this is because MPTCP’s short flow duration
makes the congestion window not fully expanded, compared to
SPTCP flows.
We next study the MPTCP performance under diverse wireless
link qualities. Figure 6 plots the ratio between throughput of
MPTCP and SPTCP (WiFi-primary), whose measurements were
conducted back-to-back, under three ranges of LTE signal strength.
Ideally, MPTCP should be at least as good as SPTCP. Surprisingly,
when LTE signal strength is poor, for 20% of downloads, SPTCP
provides higher throughput than MPTCP. We found this is due to
the limited receive window size. Compared to SPTCP, MPTCP
requires a larger (connection-level) receive window buffer to
absorb out-of-order arrival from multiple paths in particular when
the paths have diverse qualities. The default upper limit of the
receive window is set too small on Android. We confirmed
this through controlled experiments (good WiFi quality, -116dbm
LTE signal strength), and observed a strong correlation (Pearson
coefficient of 0.79) between MPTCP instantaneous throughput